[triton-ext] Fix garbage string in reported errors#9687
Merged
Conversation
When loading an extension library, it is possible that the library is
reported invalid by `llvm::sys::DynamicLibrary::getPermanentLibrary`;
e.g., if the loaded library has undefined symbols. When trying to add
dialects in [triton-ext], I observed some garbage output when loading
extensions:
```console
$ LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib
TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
LLVM ERROR: {X��J�iij(��h��[ijh��x����������
Aborted (core dumped) LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
```
I tracked this down to incorrect usage of `llvm::Twine` and
`llvm::createStringError`. Suspecting that the string messages were not
being moved into the error and thus being corrupted by stack movement, I
switched all uses of `llvm::createStringError` to use the pattern I see
in LLVM. This fixes the garbage error string problem so now I see the
proper error:
```
LLVM ERROR: Failed to load plugin library: triton/build/install/lib64/libtriton.so: undefined symbol: _Py_NoneStruct
```
[triton-ext]: https://github.com/triton-lang/triton-ext
lezcano
approved these changes
Mar 10, 2026
raymondtay
pushed a commit
to raymondtay/triton
that referenced
this pull request
Mar 22, 2026
When loading an extension library, it is possible that the library is
reported invalid by `llvm::sys::DynamicLibrary::getPermanentLibrary`;
e.g., if the loaded library has undefined symbols. When trying to add
dialects in [triton-ext], I observed some garbage output when loading
extensions:
```console
$ LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib
TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
LLVM ERROR: {X��J�iij(��h��[ijh��x����������
Aborted (core dumped) LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
```
I tracked this down to incorrect usage of `llvm::Twine` and
`llvm::createStringError`. Suspecting that the string messages were not
being moved into the error and thus being corrupted by stack movement, I
switched all uses of `llvm::createStringError` to use the pattern I see
in LLVM. This fixes the garbage error string problem so now I see the
proper error:
```
LLVM ERROR: Failed to load plugin library: triton/build/install/lib64/libtriton.so: undefined symbol: _Py_NoneStruct
```
[triton-ext]: https://github.com/triton-lang/triton-ext
jvican
pushed a commit
to jvican/triton
that referenced
this pull request
Mar 27, 2026
When loading an extension library, it is possible that the library is
reported invalid by `llvm::sys::DynamicLibrary::getPermanentLibrary`;
e.g., if the loaded library has undefined symbols. When trying to add
dialects in [triton-ext], I observed some garbage output when loading
extensions:
```console
$ LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib
TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
LLVM ERROR: {X��J�iij(��h��[ijh��x����������
Aborted (core dumped) LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
```
I tracked this down to incorrect usage of `llvm::Twine` and
`llvm::createStringError`. Suspecting that the string messages were not
being moved into the error and thus being corrupted by stack movement, I
switched all uses of `llvm::createStringError` to use the pattern I see
in LLVM. This fixes the garbage error string problem so now I see the
proper error:
```
LLVM ERROR: Failed to load plugin library: triton/build/install/lib64/libtriton.so: undefined symbol: _Py_NoneStruct
```
[triton-ext]: https://github.com/triton-lang/triton-ext
plotfi
pushed a commit
to plotfi/triton
that referenced
this pull request
Apr 8, 2026
When loading an extension library, it is possible that the library is
reported invalid by `llvm::sys::DynamicLibrary::getPermanentLibrary`;
e.g., if the loaded library has undefined symbols. When trying to add
dialects in [triton-ext], I observed some garbage output when loading
extensions:
```console
$ LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib
TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
LLVM ERROR: {X��J�iij(��h��[ijh��x����������
Aborted (core dumped) LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
```
I tracked this down to incorrect usage of `llvm::Twine` and
`llvm::createStringError`. Suspecting that the string messages were not
being moved into the error and thus being corrupted by stack movement, I
switched all uses of `llvm::createStringError` to use the pattern I see
in LLVM. This fixes the garbage error string problem so now I see the
proper error:
```
LLVM ERROR: Failed to load plugin library: triton/build/install/lib64/libtriton.so: undefined symbol: _Py_NoneStruct
```
[triton-ext]: https://github.com/triton-lang/triton-ext
(cherry picked from commit 47f9e51)
plotfi
pushed a commit
to plotfi/triton
that referenced
this pull request
Apr 8, 2026
When loading an extension library, it is possible that the library is
reported invalid by `llvm::sys::DynamicLibrary::getPermanentLibrary`;
e.g., if the loaded library has undefined symbols. When trying to add
dialects in [triton-ext], I observed some garbage output when loading
extensions:
```console
$ LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib
TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
LLVM ERROR: {X��J�iij(��h��[ijh��x����������
Aborted (core dumped) LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
```
I tracked this down to incorrect usage of `llvm::Twine` and
`llvm::createStringError`. Suspecting that the string messages were not
being moved into the error and thus being corrupted by stack movement, I
switched all uses of `llvm::createStringError` to use the pattern I see
in LLVM. This fixes the garbage error string problem so now I see the
proper error:
```
LLVM ERROR: Failed to load plugin library: triton/build/install/lib64/libtriton.so: undefined symbol: _Py_NoneStruct
```
[triton-ext]: https://github.com/triton-lang/triton-ext
(cherry picked from commit 47f9e51)
(cherry picked from commit fa5aea3)
Merged
atalman
pushed a commit
that referenced
this pull request
Apr 10, 2026
[triton-ext] Update plugin extension changes for release 3.7.x cherry-picking the following plugin extension changes since January: - **[triton-ext] Fix garbage string in reported errors (#9687)** - **[triton-ext] add string arguments to addPass API (#9691)** - **[triton-ext][FrontEnd] Custom DSL Plugin Ops (#9626)** - **[triton-ext] Drop LLVM_BUILD_SHARED_LIBS, enable libtriton visibility through TRITON_EXT_ENABLED (#9783)** - **[triton-ext] Pass a single `PluginInfo *` pointer (#9748)** - **[triton-ext] plugin extension's version check (#9937)** --------- Co-authored-by: Andrew Brown <andrew@kernelize.ai> Co-authored-by: Corbin Robeck <robeck@meta.com>
plognjen
pushed a commit
to plognjen/triton
that referenced
this pull request
Apr 14, 2026
When loading an extension library, it is possible that the library is
reported invalid by `llvm::sys::DynamicLibrary::getPermanentLibrary`;
e.g., if the loaded library has undefined symbols. When trying to add
dialects in [triton-ext], I observed some garbage output when loading
extensions:
```console
$ LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib
TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
LLVM ERROR: {X��J�iij(��h��[ijh��x����������
Aborted (core dumped) LD_LIBRARY_PATH=llvm-27d654c4-linux-x64/lib TRITON_PASS_PLUGIN_PATH=build/lib/libexample.so triton-dacfe7ad-linux-x64/bin/triton-opt
```
I tracked this down to incorrect usage of `llvm::Twine` and
`llvm::createStringError`. Suspecting that the string messages were not
being moved into the error and thus being corrupted by stack movement, I
switched all uses of `llvm::createStringError` to use the pattern I see
in LLVM. This fixes the garbage error string problem so now I see the
proper error:
```
LLVM ERROR: Failed to load plugin library: triton/build/install/lib64/libtriton.so: undefined symbol: _Py_NoneStruct
```
[triton-ext]: https://github.com/triton-lang/triton-ext
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When loading an extension library, it is possible that the library is reported invalid by
llvm::sys::DynamicLibrary::getPermanentLibrary; e.g., if the loaded library has undefined symbols. When trying to add dialects in triton-ext, I observed some garbage output when loading extensions:I tracked this down to incorrect usage of
llvm::Twineandllvm::createStringError. Suspecting that the string messages were not being moved into the error and thus being corrupted by stack movement, I switched all uses ofllvm::createStringErrorto use the pattern I see in LLVM. This fixes the garbage error string problem so now I see the proper error: